Моя производительность в написании программ

[creative]

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

[arseniiv]

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

[Zealint]

creative в сообщении #356947 писал(а):

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

А Вы что, реально думаете, будто высокооплачиваемые программисты в чём-то умнее? Во-первых, получать много денег и быть умным - это разные вещи, во-вторых, программист - это почти самое низкое звено. Годам к 28 пора занимать руководящую должность. Кого первого начали выгонять с работ в начале Кризиса? Программистов, конечно. Они просто не нужны в таком количестве. А вот человека, который пишет документацию, вряд ли выкинут с работы при сокращении.

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

[y_nikolaenko]

ewert писал(а):

... Это как-то немыслимо. Нормальный рабочий процесс примерно таков:...

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

[arseniiv]

Блок-схема если только в обобщённом виде или что-то типа алгоритма на метаязыке в голове. Традиционная блок-схема уже никому не нужна.

[y_nikolaenko]

arseniiv в сообщении #357002 писал(а):

Блок-схема если только в обобщённом виде или что-то типа алгоритма на метаязыке в голове. Традиционная блок-схема уже никому не нужна.

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

[vek88]

Zealint в сообщении #356896 писал(а):

Дело в том, что это простая задача. То есть это не совсем честно.

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

Zealint в сообщении #356896 писал(а):

По поводу Вашей задачи о мудрецах. Похожую видел на олимпиаде по программированию.

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

Zealint в сообщении #356896 писал(а):

То есть несправедливо измерять производительность абстрактными задачами. Её вообще чем-то конкретным едва ли можно измерить. Каждый человек заточен под свой класс задач.

Согласен, но хоть так можно попробовать.

allchemist в сообщении #356906 писал(а):

так что задача явно не подходит. vek88, давайте другую :)

Я ведь назвал Задача 1 - попробую предложить другие, но и Вы попробуйте предложить подходящие.

-- Вт сен 28, 2010 18:06:03 --

arseniiv в сообщении #356944 писал(а):

Может, подойдёт задача написания интерпретатора простого языка?

Когда-то давно пришлось написать интерпретатор математических формул - получилось 2000 строк на C. Хотя что может быть проще вычислений по формулам типа $z = sin^2(x) + cos y$?

[Maslov]

Zealint в сообщении #356981 писал(а):

программист - это почти самое низкое звено. Годам к 28 пора занимать руководящую должность. Кого первого начали выгонять с работ в начале Кризиса? Программистов, конечно. Они просто не нужны в таком количестве. А вот человека, который пишет документацию, вряд ли выкинут с работы при сокращении.

Ошибаетесь.

Во-первых, документацию пишет "технический писатель" (technical writer) -- мягко говоря, не самая высокая должность; в любом случае, не "руководящая".
Другое дело, если Вы имеете в виду аналитиков, т. е. специалистов, формирующих требования к разрабатываемому программному обеспечению. Но это тоже обычно никакие не руководители.

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

Ну а "руководящие" должности -- это обычно как раз ведущие программисты (lead developers) и руководители проектов, причём, довольно часто эти две роли совмещаются.

y_nikolaenko в сообщении #357013 писал(а):

Лично у меня написание программы, как таковой, от общего времени разработки занимает малую толику времени.

Так и должно быть. В типичном проекте по разработке программного обеспечения собственно программирование -- это около 30% трудозатрат; остальное -- управление требованиями, проектирование, тестирование и т. п.

Что же касается "блок-схем", то существует довольно много графических нотаций, позволяющих отразить тот или иной аспект структуры или функционирования программного обеспечения. В частности, UML включает более десятка видов таких диаграмм. Какие-то из них более полезны в конкретном проекте, какие-то менее, и выделить один в качестве универсального невозможно. (К Ханойской башни все они вообще малоприменимы :))

[vek88]

creative в сообщении #356947 писал(а):

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

Вы сами себе создаете комплекс неполноценности. Кстати, то что Вы решаете за час, многие не решат и за сутки. Так что поменьше гундосьте, а занимайтесь своим делом в свое удовольствие.

Да мало ли что достигли другие - вот кто-то полком в 16 лет командовал, так что ж нам всем удавиться?

[allchemist]

Цитата:

Я ведь назвал Задача 1 - попробую предложить другие, но и Вы попробуйте предложить подходящие.

Цитата:

Может, подойдёт задача написания интерпретатора простого языка?

Отличный вариант, осталось только язык придумать позаковыристей. Brainfuck пойдет? :)


От себя могу предложить что-нибудь из идей John Koza (генетическое программирование). В самом простом случае - задача символьной регрессии, описанная в начале его книги Genetic Programming. Если будут трудности с ее поиском, могу изложить вкратце суть задачи и некоторые идеи.

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

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

[vek88]

allchemist в сообщении #357034 писал(а):

От себя могу предложить что-нибудь из идей John Koza (генетическое программирование). В самом простом случае - задача символьной регрессии, описанная в начале его книги Genetic Programming. Если будут трудности с ее поиском, могу изложить вкратце суть задачи и некоторые идеи.

ИМХО читать некую книгу - это уж слишком. Все-таки хорошо бы предложить достаточно простую и не слишком трудозатратную задачу. Вот, например:

Задача 2. Требуется написать интерпретатор арифметических формул:
- на входе арифметическое выражение, правильно построенное из чисел, знаков сложения, вычитания, умножения и деления (скобок нет)
- приоритет операций - пусть как в Excel
- на выходе - результат вычисления арифметического выражения.

Если задача слишком громоздкая, можно упростить - оставить только сложение и умножение. Пусть это будет Задача 2а.

ЗЫ. Приведенные выше программы решения Задачи 1, как бы сказать, не имеют очевидной структуры. А потому ИМХО даже как-то не очевидно - правильные они или нет. Хотя, в принципе, кажется, похоже. А вот в post356906.html#p356906 рекурсивное решение ИМХО более понятное и очевидное

[allchemist]

фактически, вы предлагаете парсер infix->prefix (и наоборот). делал это пару раз, больше десяти минут не тратил.

ладно, сейчас изложу вкратце основную идею задачи.

пусть будет так, если кого-то заинтересует.

Есть набор данных, отвечающих какой-то функции (набор пар значений x,y). необходимо аппроксимировать эти данные с помощью функции в аналитическом виде. например, для двухмерной функции аналичтиеская запись будет содержать одну переменную (x).

Функция представляется в виде дерева, каждая точка ветвления которого - это оператор (сложение, вычитание, умножение, sin, cos и т.д.). В вершинах дерева т.н. терминалы, то есть самовычисляемые выражения - числа или переменная (x).

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

Из конечного дерева получаем удобочитаемую аналитическую запись функции и применяем упрощения (скобки раскрываем, убираем нули, единицы, вещи типа x-x и т.д.)

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

[Zealint]

vek88 в сообщении #357038 писал(а):

Задача 2. Требуется написать интерпретатор арифметических формул:
- на входе арифметическое выражение, правильно построенное из чисел, знаков сложения, вычитания, умножения и деления (скобок нет)
- приоритет операций - пусть как в Excel
- на выходе - результат вычисления арифметического выражения.

Сейчас решать не хочу, но лет 5 назад решал на олимпиаде, а потом ещё многократно совершенствовал. Как сейчас помню, решающая рекурсивная функция - всего 22 строки + 4-5 строки на функцию перевода строки в целое число. Разрешаются только целые числа, круглые скобки, четыре арифметических операции. Пишется 10-12 минут. Разумеется, нет проверки на то, что введенное выражение корректно. С проверкой корректности там еще строк 80 было. Опять нечестно получается: задача слишком классическая, её сейчас любой школьник-олимпиадник средней руки напишет. Ещё модно стало с длинной арифметикой делать, это усложняет кодирование минут на 10-15.

С другой стороны, убойные задачи типа 6 ферзей - это тоже перегиб палки. Хотя лично меня задачи более простые перестали интересовать некоторое время назад. Кстати, скоро будет мой новый конкурс...

[allchemist]

Цитата:

мой новый конкурс

а что это?

[vek88]

ИМХО можно попытаться подвести результаты наших попыток оценить производительность программирования с помощью простых тестовых задач.

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

Позитивный результат. Дык значит все просто - преимущества получает более опытный (что-то подобное видел, делал, слышал ...). А как набраться опыта? Вижу три важнейших момента:

1. Решать реальные задачи программирования.

2. Больше общаться с себе подобными, по возможности, в процессе совместной работы. Разумеется поможет изучение и хороших книг, и участие в подобном формуме. Но работа в коллективе ИМХО - это главное.

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