Thread: Программирование

И над чем размышляет программист? XD Программист, обычно реализует алгоритм, используя при этом один из языков (sic!) программирования. Иногда, конечно, приходится придумывать алгоритмы, но это можно сравнить, например, с написанием стихов =) По большому счету что корейский, что паскаль, что галиматья в 1с - тоже набор слов, конструкций, правил. Всякие хитрые приемы, которые позволяют изъясняться эффективнее. Ну и так далее. В принципе можно и анатомию свести к конечным автоматам, внутренние управляющие сигналы, внешние датчики, триггеры, память, механизмы доступа и так далее...

>>Может быть, лучше сказать, что это какой-то сочетание между языками и математикой

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

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

Originally Posted by pushvv

И над чем размышляет программист?

Хороший программист должен размышлять надо всем. Над выбором переменных и констант, над их именами и комментариями к ним, над названиями функций и подпрограмм, над набором параметров этих функций, над размером подпрограммы (в идеале это страница), над структурой программы, над количеством комментариев в программе, над составом библиотеки вспомогательных программ, над интерфейсом программы, над понятностью кода другому программисту и т.д.
Об этом написаны книги. Например, Ван Тассел: "Стиль, разработка, эффективность, отладка и испытание программ". В моё время это был бестселлер.

Это было про стиль. А ещё есть содержание. Там вообще голову можно сломать. Я занимался имитационным моделированием морских процессов. Приходилось моделировать распространение звуковой волны в воде и т.д. И надо было в одной модели с заданной точностью моделировать процессы, которые идут на очень разных скоростях. Пришлось придумать метод пересчёта шага по времени (метод дельта T). Там кандидатские и докторские светили. Вообще, я не знаю более интересной работы, чем инженер-программист. Это захватывало так, что думал об этом и в транспорте, и несколько дней в отпуске, пока не отпускало.
Но есть одно но. Интересно делать только свои программы. Чужие причёсывать не интересно.
Вообще, сделать программу объёмом 100 листов и чтобы она была без ошибок - это уже не тривиальная задача. Это может только человек со стилем.

Originally Posted by Юрка

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

Хороший программист в процессе работы над этим размышлять ни в коем случае не должен. Он должен все это обеспечивать очень быстро - на интуиции и шаблонах. Хороший программист - быстрый программист. Это если говорить о собственно программистах, а не об исследователях и проектировщиках языков и компиляторов/трансляторов.

Я занимался имитационным моделированием морских процессов. Приходилось моделировать распространение звуковой волны в воде и т.д. И надо было в одной модели с заданной точностью моделировать процессы, которые идут на очень разных скоростях. Пришлось придумать метод пересчёта шага по времени (метод дельта T). Там кандидатские и докторские светили.

Это опять-таки нетипичная задача для программиста. Задача для профессионального программиста в даном случае - быстро отыскать наиболее адекватную для данной задачи библиотеку и корректно ее использовать, а не изобретать велосипед. Собственно, динамическая коррекция шага, завязанная на оценку погрешности - стандартная черта большинства профессиональных реализаций, например, численного интегрирования, МКЭ, сеток и т.п.. И там столько тонкостей, в которых можно напахать неочевидным образом, что лучше оставить это математикам-специалистам по конкретному типу численных методов, а не писать с нуля для своей предметной области.

Эта истина выстрадана мной на собственном горьком опыте.

Originally Posted by it-ogo

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

if( bool.toString().length() == 4 )

Originally Posted by CoffeeCup

if( bool.toString().length() == 4 )

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

Originally Posted by Юрка

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

Таковы современные принципы профессиональной разработки программного обеспечения. (Я же препод - быть в курсе таких вещей - моя обязанность.) Впрочем, что я говорю "современные"? RAD стал мейнстримом в начале девяностых. С тех пор все хужее и хужее. Скорость обновления рынка ПО только растет.

Но я не встречал работ, в которых приветствуется суета и отсутствие мысли.

Суету порождает излишек мысли, а не ее отсутствие.

Я работал тогда, когда мы слыхом не слыхивали о всяких матлабах. В то время мы работали на машинах серии ЕС 1060 (если не забыл) с коллективным доступом. Потом увидели первые персональные. Потом получили первые IBM. У нас в лаборатории были профессор, доцент, научные сотрудники, но никто не знал, что такое переменный шаг моделирования. Мы это с нуля осмысливали и разрабатывали.

Эх, романтика... Я сам немного такой, но мы с вами как программеры устарели с распространением интернета.

Любой русский программист, после пары минут чтения кода, обязательно вскочит и произнесет, обращаясь к себе: «Переписать это все нафиг!» Потом в нем шевельнется сомнение в том, сколько времени это займет, и остаток дня русский программист потратит на то, что будет доказывать самому себе, что это только кажется, что переписать — это много работы. А если взяться и посидеть немного, то все получится. Зато код будет красивый и правильный. Hа следующее утро русский программист свеж, доволен собой и без единой запинки докладывает начальству, что переписать этот кусок займет один день, не больше. Да, не больше. Hу, в крайнем случае, два, если учесть все риски. В итоге начальство даст ему неделю и через полгода процесс будет успешно завершен. До той поры, пока этот код не увидит другой русский программист.

Originally Posted by it-ogo

мы с вами как программеры устарели с распространением интернета.

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

Любой русский программист, после пары минут чтения кода, обязательно вскочит и произнесет, обращаясь к себе: «Переписать это все нафиг!» Потом в нем шевельнется сомнение в том, сколько времени это займет, и остаток дня русский программист потратит на то, что будет доказывать самому себе, что это только кажется, что переписать — это много работы. А если взяться и посидеть немного, то все получится. Зато код будет красивый и правильный. Hа следующее утро русский программист свеж, доволен собой и без единой запинки докладывает начальству, что переписать этот кусок займет один день, не больше. Да, не больше. Hу, в крайнем случае, два, если учесть все риски. В итоге начальство даст ему неделю и через полгода процесс будет успешно завершен. До той поры, пока этот код не увидит другой русский программист.

История прям про меня. Изначально я был в группе из трёх человек и мы ваяли верхний уровень большой модели. Придумывали как считать шаг по времени и т.д. Через несколько лет один ушёл в бизнес, другой тоже (потом свалил в Канаду). И вот оставшись в лаборатории последним могиканином (который что-то соображал в верхнем уровне), я за год самостоятельной работы перелопатил то, что мы сделали втроём, переделав 90%. И получилось то, что не получилось сделать втроём. Нам тогда руководитель лаборатории запретил делать переменный шаг по времени, сказав, что мы сами не понимаем, что это такое (и он не понимает). А в одиночку работать оказалось продуктивнее. Ни с кем не надо согласовывать, доказывать, спорить. Ввёл модуль "среды", рекомендации по шагу давали модели нижнего уровня. В итоге упростились до неприличия модули движения. Добавил интерфейс (графика, меню, редактор) и "продал" это в соседнюю тему. У них тогда программа считала, но ничего не изображала. А у меня там виды с любой точки, плавное масштабирование, процесс в динамике и т.д. Но потом понял, что это тупик и ушёл из лаборатирии. Уж очень тупые руководы были, хоть и кандидаты. А профессор был озабочен тем, как продаться на Запад. У него была книжка, но немцы ему объяснили, что голую теорию они не покупают. И вот он засадил аспиранта воплотить его бредовую теорию в ПО. Он и мне предлагал, но я честно признался, что бред не понимаю. Жалею только о том, что не захватил с собой распечатку своих шедевральных программ. Сейчас бы за чашечкой кофе любовался, вспоминал молодость, тыкал в них мордочкой молодёжь (типа, вот как надо программировать).

Originally Posted by Юрка

Думаю, что мастерство не пропьёшь. Ведь кататься на велосипеде два раза учиться не нужно, даже если это новый велосипед.
История прям про меня. Изначально я был в группе из трёх человек и мы ваяли верхний уровень большой модели. Придумывали как считать шаг по времени и т.д. Через несколько лет один ушёл в бизнес, другой тоже (потом свалил в Канаду). И вот оставшись в лаборатории последним могиканином (который что-то соображал в верхнем уровне), я за год самостоятельной работы перелопатил то, что мы сделали втроём, переделав 90%. И получилось то, что не получилось сделать втроём. Нам тогда руководитель лаборатории запретил делать переменный шаг по времени, сказав, что мы сами не понимаем, что это такое (и он не понимает). А в одиночку работать оказалось продуктивнее. Ни с кем не надо согласовывать, доказывать, спорить.

только к программированию этот подвиг танкиста не имеет отношения

Originally Posted by it-ogo

Впрочем, что я говорю "современные"? RAD стал мейнстримом в начале девяностых. С тех пор все хужее и хужее.

Не так страшен чёрт, как его малютки.
Прогресс есть. Для особо криворуких уже есть нехилый рынок CRM и иже с ними, где криворукие вполне достойно могут себя применить, невзирая на свою криворукость.. Так сказать, access diversity for hands-challenged persons.

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

Originally Posted by Crocodile

Не так страшен чёрт, как его малютки.
Прогресс есть. Для особо криворуких уже есть нехилый рынок CRM и иже с ними, где криворукие вполне достойно могут себя применить, невзирая на свою криворукость.. Так сказать, access diversity for hands-challenged persons.

CRM? Может ты имеешь в виду CMS? Я как-то попробовал Moodle и Джумлу. Нет уж, для этого я слишком тупой. Ну его в баню!

Originally Posted by it-ogo

Хороший программист - быстрый программист.

Так может рассуждать или начальник, у которого в подчинении программисты (мыслитель здесь я, а вы исполнители), или программист стиля тяп-ляп. Но я не встречал работ, в которых приветствуется суета и отсутствие мысли. Слесарь-торопыжка запорет размеры, лесоруб-торопыжка завалет на себя ёлку. Программист-торопыжка сделает нечто, что нужно отлаживать 5 лет, а потом выбросить.

Originally Posted by it-ogo

Задача для профессионального программиста в даном случае - быстро отыскать наиболее адекватную для данной задачи библиотеку и корректно ее использовать, а не изобретать велосипед. Собственно, динамическая коррекция шага, завязанная на оценку погрешности - стандартная черта большинства профессиональных реализаций, например, численного интегрирования, МКЭ, сеток и т.п.

Я работал тогда, когда мы слыхом не слыхивали о всяких матлабах. В то время мы работали на машинах серии ЕС 1060 (если не забыл) с коллективным доступом. Потом увидели первые персональные. Потом получили первые IBM. У нас в лаборатории были профессор, доцент, научные сотрудники, но никто не знал, что такое переменный шаг моделирования. Мы это с нуля осмысливали и разрабатывали.

Originally Posted by Юрка

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

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

и вообще хороший программист, это программист который может работать над одним кодом в команде из нескольких человек, поэтому Д'Артаняны в программировании не нужны. Учитывая что у большинства людей технического склада присутствует OCD в той или иной степени тяжести, то работа в команде это наверное пункт номер 3 по значимости в карьере программиста (после знания среды разработки и умения обучаться)

Originally Posted by Юрка

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

Цитата в тему.