Как бывает и дураку понятно. Я бы сказал что все науки идут от психологии и к ней сводятся.
Самое глубинное знаниее в том почему "так бывает"
Вот агностики на него даже боятся отвечать. А почему бояться? -Слабая психика!

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

Или вот скажем стойкость криптоалгоритмов. Серьезные математики сидят и гадают, ну насколько же сложно ломануть их криптозащиту. Может года хватит, а может 10 лет. Все зависит от вероятности появления некого гения. Опять на психику свалили проблему.

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

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

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


Вас кто-то очень жестоко обманул и дезинформировал. Единственное и основное у нас - "что доказано, то либо не существует, либо не существует, смотря что именно доказано. Что не доказано - то может существует, а может и нет, и слепо верить во что-то из двух крайностей недопустимо". А ответ на вопрос "почему так бывает" - стремление объяснить явление, и доказать, что это объяснение верно, это святое - это вообще основная цель.

это Вы о ком?

Первый год учусь в аспирантуре. Начинаю писать диссертацию на тему "Исследование методов тестирования и отладки ПО встраиваемых систем реального времени". В этом направлении есть где развернуться, и на докторскую хватит.




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

Редкий современный программист в своем деле использует какие-либо другие инструменты кроме пошагового выполнения программы и очень долгого и очень-очень пристального взгляда на исходный код. Вот вам и не паханное поле для научной деятельности. Я уже больше года занимаюсь поиском трудов на эту тему, все что есть - написано американцами, а переводить и внедрять в учебный процесс никто не торопится. Неудивительно почему у нас отношение к программистам как к токарям. Но ведь токарю не приходится тратить 95% рабочего времени на пошаговое усовершенствование и вылизывание уже выточенной детали.

А как же теория?


Началось то с того и потом подхвачено, что наука обязательно должна предусматривать создание теории. А в вашем предмете исследований есть теория?

Вы путаете науку и диссертацию. Сколько бы было тогда чудных теорий. Диссертация - просто-напросто, квалификационная исследовательская работа.

Взято с википедии, т.к. под рукой нет ни книжек ни конспектов по философии.

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

Создание абсолютно новых теорий или открытие принципиально новых направлений - удел докторских диссертаций. А в этом направлении открыто совсем немного, ибо программирование наука (не побоюсь этого слова) совсем молодая.

Ну так обобщение будет?



Можете хоть одну теорию в программировании назвать? Люди ж просят.
Как можно обобщать если нет теориии и нет доказательств? Что доказательствами будет?
Ваш личный опыт по поиску багов тем или иным способом? Агностики вас поднимут на смех.

Ваш пост совсем не в поддержку программистов.

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

Это и есть самая-самая инженерная работа.

Ну вот уже что-то, хотя не понятно, как это относится к программированию, т. к. его определение так никто и не дал.

Это смотря отладка чего. Если при разработке алгоритма была допущена ошибка, то это ошибка не программирования, а разработки алгоритма (не следует забывать, что программа - это лишь один из вариантов реализации алгоритма, и в общем случае разрабатывает алгоритм никак не программист. Другой ввриант например реализация его схемотехнически), то один вопрос. А если ошибка была в процессе программирования, т.е. программа работает не так, как положено по алгоритму - второй вопрос... IMHO.

Кстати - схемотехника - брат программирования, только в части разработки аппаратной части, а не программной. И по схемотехнике что-то диссертаций не наблюдается. Хотя там тот же дебаг, называемый наладкой, и вообще очень много общего.

Ну, наверное, вы правы, но сути это не меняет - всё-равно работа инженерно-наладческая.

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

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




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



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



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



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

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


Это не работа программиста. Это значит, что программист совмещает кроме собственно программиста, еще и аналитика, математика, верификатора, а может еще и электронщика и физика. Формально работа программиста - только описание алгоритма при помощи ЯП и отладка до полного соответствия одного другому.

Нуу.., эт прокол.

VHDL, Verilog, System C и т.д. есть языки программирования. И это уже не схемотехника, а чистое программирование.
Ход мыслей вообще интересен. Программирование захватывает все большую часть электроники.
Некогда области бывшие схемотехникой становятся программированием.


Это работа именно программиста. Ничего программист не совмещает это все его прямые обязанности.
Вернее это обязанности эмбеддера-программиста. На моем опыте при принятии на работу программиста встраиваемых систем от него всегда требуется аналитика, численные методы, навыки отладки и схемотехника. Это все и проходят программисты в универе.
Для программиста PC и систем позволительно и не знать схемотехнику потому что ему надо бороться с гигантскими API и абстракциями и патернами ООП.

Я бы даже то что тут называют математикой отнес бы к программированию.
Ну никогда бы так называемый "технарь-математик" не придумал бы алгоритм CORDIC. Просто потому что технари совершенно не в курсе ограничений вычислительных платформ и не могут их учесть.
Более того технари не в состоянии предоставить алгоритм в истинном понимании этого слова.
Алгоритмы может составить только программист знающий как можно представить данные (типы, структуры) и что с ними можно сделать (набор либ, API, и т.д.) и как обеспечить отлаживаемость и надежность.
Программисты вынуждены вежливо слушать "технарей" чтобы потом все сделать по другому, это подтвердит любой программист.
Теже DSP алгоритмы. С плавающей точкой на ура, любой дядя Вася из учебника Скляра может тыкать формулами.
А на деле программист должен кондиционировать сигналы, привести к тем типам данных которые есть, обеспечить быстродействие кода который бы еще и не конфликтовал с другим кодом на платформе, а еще подумать и о переносимости, а еще побороться со средой разработки и т.д.

AlexandrY, подписываюсь под каждым словом

НИКОГДА! Это языки описания аппаратуры (hardware description language), ни коим образом языками программирования не являются.


Круто... По-вашему Бриггс был программистом в 1624-ом году (когда была первая публикация этого метода, тогда еще не носившего название CORDIC) ? Да и обобщение метода Бриггса на комплексные числа, сделанное Волдером, тоже не является работой программиста.

Можно взять и другой пример "алгоритм" G.726 - его придумали именно "технари-математики" для реализации в железе. Для программирования он конкретно неудобен ни на одной из платформ. Так что Ваш тезис о том, что алгоритм всегда разрабатывается программистами и только ими некорректен. Он может ими разрабатываться, но вовсе не обязан. Или например RSA - эта тройка все закоренелые математики. А не программисты.

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



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

Аха, пошел программист к математику, и сказал, разработай ка мне алгоритм, скажем, фильтра Батерворта для чисел с фиксированной запятой в формате 1:23 и чтобы выполнялся не дольше 0,5 мкс на частоте 4 МГц на микроконтроллере ATtiny. Потом за пять минут написал программу, и отдал верификатору на проверку. Внимание вопрос, зачем нужен такой "программист"? И посмотрите самый первый пост, об этом автор темы и повествует.

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

Между прочим язык Си тоже язык описания алгоритмов функционирования.

Вероятно, я соглашусь с тем, что и области деятельности и определения несколько размыты и не совсем ясны, не то чтобы определены. Но давайте спросим себя, а кто был этот самый Баттеворт или Нейман или Хаусхолдер, или Воеводин или Тихонов. Конечно, Баттерворт не думал о ATtiny, но их тогда и не было, было что-то другое. А вот о фиксированной точке он точно думал и ещё куча численных математиков. И много ли "чистых" программистов работает, например, в задачах CFD, квантовой химии или ещё какого численного моделирования? :) (P.S. Прятная дискуссия, читаю с удовольствием, особенно SM)

Все они были ученые, которые создали методы/инструменты для программистов. В то же время без мало-мальского представления той математики, программист не сможет реализовать тот же фильтр. Так же как без представления о программировании тот же Баттерворт никогда не создаст свой фильтр. Как-то так

Да вот после таких ребят Брюс Шнаейр и был вынужден выпустить "Практическая криптография" и еще кучу книг по криптографическим протоколам.


Поскольку эта братия сумела создать только малопригодную схему. А вся сила то в реализации!
Сам RSA алгоритмик от силы пару килобайт занимает. А реализация IPSec с SSL может занять под мегабайт.
Чтож там программисты то намутили а?

Ну и я уж молчу что у Дональда Кнута книги содержат слово "программирование", а не скажем "математика для кодеров"
http://ru.wikipedia.org/wiki/%D0%9A%D0%BD%...%B2%D0%B8%D0%BD

То что Кнут ученый наверно никто отрицать не станет. И он ученый в области программирования, "разработчик нескольких известных программных технологий"
Дело в том что его математика порождена программированием, без компьютеров ее бы не было.

Сможет, и легко. Точно также, как и токарь сможет по чертежу со всеми указанными размерами выточить деталь, так и программист по грамотно описанному алгоритму (с точностью до точности представления той или иной переменной, правил округления, и т.д.) составить программу. А вот наоборот - далеко не каждый токарь сможет разработать грамотный чертеж детали, которая выполняла бы свою определенную функцию допустим в двигателе, он для этого должен быть еще и конструктором, и физиком, и ..., так и не каждый программист сможет разработать, к примеру, алгоритм сжатия речи с потоком в 1200 бит/с, заданным SNR и разборчивостью, он для этого должен быть еще математиком, и еще тем же физиком (чтобы разработать нужную модель тракта от гортани до уха), и ..., а не только программистом.

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



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

Насчет файловых систем это пальцем в небо. Если бы цель была именно такая, то всем бы хватало одной файловой системы.



Об истории вопрос не стоит, есть человек и он занят наукой называемой "программирование"

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

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

Что касается файловых систем - это именно так. Была бы задача решена однозначно - была бы одна ФС и все бы ей пользовались. Но наборы критериев оптимальности у всех разные, и решения разные, и, наверняка, еще не совсем оптимальные. Там науки (математики) еще мама не горюй, в задачах по оптимальному размещении данных на носителях.


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

Хорошо, но как называется тогда эта наука?

Вот некоторые аспирантские специальности:
05.13.11 Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей
05.13.15 Вычислительные машины, комплексы и компьютерные сети
05.13.17 Теоретические основы информатики (кстати о теории)
05.13.18 Математическое моделирование, численные методы и комплексы программ

источник http://aspirantura.spb.ru/other/spec.html

Как можно заметить, Российская Академия Наук, все же считает программирование наукой, причем наукой тесно связанной с математикой.

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

Пойдите почитайте паспорта этих специальностей прежде чем делать такие громкие заявления.
Для примера 05.13.11

Да почему же не наукой ?! Самой натуральной наукой! Кто-то математикой, кто-то педагогикой.
Опять же токарное дело приведу для примера... Диссертаций на тему токарной обработки - море морское. Но наука - металловедение, а не "токарное дело". Так и тут - диссертаций по программированию много - но наука - математика.



И что - каждый пункт - практически 100%-ный раздел математики, применяемый в частности и в описании процесса программирования.

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



я видимо читать разучился

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

Не читать, а понимать, о чем речь. Синтаксис и семантика, как и язык - чисто математические термины, а именно из ее раздела дискретной математики, а именно из ее раздела математической кибернетики, а именно из ее раздела математической информатики. Построение и оптимизация - это чисто математические процессы - рассказать откуда? Или сами найдете? Ну и т.д.

Ха, опять неувязочка.


Читаем:
http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%...%B8%D0%BA%D0%B0

и понимаем что программирование - математическая наука. Все, вопрос надеюсь закрыт?

Теперь перейдем к исходному.

Раз "технарь" не может освоить эту математическую науку, хотя математику кое в чем знает, то это программисты должны давать задания технарям как более квалифицированные в среднем специалисты чем технари.
Что собственно и есть. Эти программисты называются аналитики.
В отсутствии ставки выделенного аналитика и при необходимости разработки ПО, право решения следует отдавать тем кто занимается программированием.

Во первых в википедии можно написать что угодно. Но это не тот случай.

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

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

ЗЫ. И совсем оффтопик. По собственной статистике, когда из программистов с поверхностным знанием схемотехники приходят в проектирование схемотехники заказных ИМС или конфигураций FPGA, то это очень тяжелый случай в 90% случаев. Ну никак не могут они понять, что это такое HDL и как на нем писать, и делают огромное количество одинаковых ляпов в основном в написании такого, что физически не может быть синтезировано, или синтезируется крайне не оптимально. Приходится их сначала заставлять рисовать схему того, что от них требуется, а потом описывать ее на HDL. И только пройдя через долгое битье головой об стену они начинают сразу, без схем, делать грамотные HDL-описания. А вот если наоборот, разработчик схемотехники такого уровня (ASIC/FPGA) с поверхностным знанием программирования уходит в программисты - то это получается практически сразу ас в оптимизации программ, так как он лучше многих понимает, что и как вычисляет процессор, как он устроен, как обменивается с памятью, с внешними устройствами, и т.д. А если он еще и математик - то и в оптимизации алгоритмов на заданную архитектуру.

И еще раз. У каждой науки есть теоретическая (научная) и практическая часть. Написание программ - деятельность инженерная. Создание и усовершенствование методов и инструментов программирования - научная. Если я решаю квадратное уравнение я занимаюсь наукой? А если я решая это квадратное уравнение придумал такое понятие как корень из минус единицы? В первом случае я занимаюсь инженерной деятельностью, во втором я создал новый инструмент математического аппарата, занимаясь научной деятельностью. Вы, SM, как будто ни единого раза не прочитали мои остальные подобные высказывания, и по прежнему твердите что написание программ деятельность ненаучная (да кто же спорит-то).

Насчет связи с математикой видимо все же истина где-то по середине. Все те специальности что я перечислял РАН относит к технической и физико-математической отрасли науки. О чем это говорит - математика - огромная отрасль науки. И вашими, SM, рассуждениями к математике можно свести практически любую техническую науку. К чему я собственно клоню - программирование как наука лежит на стыке технических и физико-математических отраслей, грубо говоря подраздел математики.

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

ИМХО, занимаясь любой наукой приходится задействовать множество других наук.

Поддерживая офтопик. В университете нас сначала учили программировать в традиционном понимании этого слова (галимый паскаль), на четвертом курсе потребовалось изучить VHDL. Ни для кого в группе не составило труда переключиться. Нет ничего в этом сложного. Я понимаю что сейчас говорю о учебных задачах. Но если к вам, SM, попадают программисты только что из университета, и вы хотите от них владения HDL, естественно что для них будет это задача непростая. Для них принципе любая реальная задача будет непростой, ввиду отсутствия необходимого опыта. А судя по вашему, SM, подходу, вы в программисте просто убиваете все творческие начала, не давая ему самостоятельно разработать тот же математический алгоритм. Я в таких условиях долго на работе не задержусь - факт. Не буду заниматься работой от которой не получаю удовольствия. Вот и остаются у вас ребята, которые довольны тем что просто повторяют на ЯП разжеванные решения.

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

Так в том и дело, что "отключение при низком уровне батарей" это тоже матобработка, только математика в данном случае не ТФКП к примеру, как в большинстве задач по ЦОС, а теория автоматов, о чем большинство "программистов" забывают. Программисту остается лишь описать этот автомат на ЯП. Просто каждой (и любой) задаче, которую можно решить с использованием программирования как инструмента для решения, существует свой матаппарат, которым она решается прежде, чем будет запрограммирована. И именно поэтому я отделяю программирование как чистое ремесло от математики - как науки (в данном случае) о решении задач и разложении этой задачи на алгоритмы. Программист, решая любую зазачу и составляя, пусть даже в уме, алгоритм, работает аналитиком и математиком, после чего вспоминает, что он программист, и программирует только что разработанный им алгоритм с использованием ЯП. И еще один признак, что программирование это не наука, а ремесло по преобразованию одного вида алгоритма в другой - то, что любой алгоритм, который можно реализовать программно, можно также реализовать и аппаратно, без привлечения программиста вообще. Будут все те же математические сущности, автоматы, выражения, и т.д., просто реализованные на практике другим методом.

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


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

Здесь математика тоже ремесло. Ничего научного в разработке математического алгоритма нет.

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

Не согласен ни с чем



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

Про эквивалентную аппаратную реализацию эту байку от вас слышим давно. Ну реализуйте Windows CE аппаратно!
Даже если и попроще все равно будете использовать программирование на Verilog, а еще и в тихаря RISС прикрутите и будете его на ассемблере програмить.

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

А теперь открываем книгу "Математика для программистов игр". И видим там что должен знать программист из математики. Там почти весь Корн и еще физика с оптикой в придачу.

Или открываем книгу "Построение интерпретаторов и компиляторов". На протяжении всей книги нет ни слова "математика" ни одного математического знака! Кто учился по Корну не признает здесь математики. Это просто другая математика, компьютерная.






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

Так откройте другую книгу. По дискретной математике. По математической кибернетике и математической информатике (это разделы дискретной математики). И увидите там все это. И про кодирование, и про лексический/синтаксический анализ, и про все остальное, связанное с програмированием. Возможно откроете для себя много нового. Если Вы ее никогда не открывали, это не говорит о том, что ее не существует. Да и во всеобъемлющие справочники по математике я не верю, это IMHO невозможно, чтобы один человек охватил всю ее целиком...


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


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

Насчет Win CE аппаратно - это ВОЗМОЖНО и без встраивания RISC. Т.е. некий аппаратный блок, реализующий все ее API через какой либо интерфейс. (попробуйте доказать обратное). Я, естественно, этого делать не буду, так как вряд-ли это кому-то нужно, и вряд-ли это будет пользоваться спросом. Но, главное, что это ВОЗМОЖНО. И программирование на Verilog я использовать не буду, так как это невозможно. Еще раз, на любом HDL описывают устройства вцелом, но не программируют их. "Программирование на HDL" это наиболее распространенная ошибка у начинающих освоение HDL, и ничего более.

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

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


С обсуждения бизнес процесса обсуждение и началось. В этом бизнесе этих ученых называют программистами


Как интересно. Оказывается там теория есть какая-то.
Вот вам журнал по практическому функциональному программированию http://fprog.ru/
Найдите там теорию.
Наверно вы спутали термины и не о том хотели сказать. А то тогда придется признать наличие теории и у языка Basic



ALU в вашем блоке будет? Думаю будет. Память вообще обязательно. Микрокод выполняемый тож будет. Значит будет и программирование (неважно что в ROM или даже перемычками), а следовательно это не будет аппаратным решением. Вот и все доказательство.
Самое то забавное что эта система сама в процессе работы может создавать программы. (скрипты там, промежуточный код и проч.) и вы никак не превратите ее в чистый жесткий аппарат иначе это будут не винды.
Да и вообще в широком смысле любой алгоритм это программирование.
Даже ввод принципиальной схемы с кучей однообразных блоков в современных средах разработки превращается в программирование.
В Altium-е нормальный спец уже должен знать как минимум язык разработки скриптов.

Во первых теоретическая подоплека есть у любого языка. И вообще "язык" это вполне четко определенное понятие из одного из разделов математики.
Во вторых искать в журналах по практическому программированию теорию - бессмысленно, они же по практическому программированию, а значит для тех, кого расширение кругозора в сторону теоретических основ не интересует, и, как прямое следствие, научная работа, без теории невозможная, тоже..
В третьих - незнание теории никак не говорит о ее отсутствии. И термины я не перепутал. У функционального программирования есть полноценная теория. Изучили бы для начала хотя бы азы дискретной математики, например "азбуку" "Т. С. Соболева, А. В. Чечкин "Дискретная математика", Академия, 2006 г.", и потом главу 6 в "А. Филд, П. Харрисон Функциональное программирование: Пер. с англ. — М.: Мир, 1993.". И окажется, что "оказывается там теория есть какая-то", без которой, кстати, рассматривать что либо вообще как науку нельзя. Может быть, заинтересуетесь теорией. Но судя по Вашим высказыванием - врядли, так как Вы, похоже, убежденный практик, считающий теоретические основы этой практической деятельности лишним и ненужным знанием.

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

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

"технарь-математик"- это кто такой???
А вообще, как я понимаю, Вы выделяете программистов в отдельную группу? Т. е. программисты не технари? Возможно, доля истины в этом и есть, но по-моему пока всё-таки они близки к технарям.


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

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

Именно аналогичный этому пример я и приводил.

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

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


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

А Вы не думали о том, что формула это по сути и есть программа какого-то процесса? А виртуальный язык всё-равно сведется к математике.

А где Вы нашли там программирование? Здесь именно говорится о реализации задач программирования - математической, аппаратной...

Резюмируя, программирование - это процесс описания уже известного языком, понятным исполнителю (ЭВМ), не вносящий ничего нового и неизвестного в человеческое знание. Реализация же программирования (создание языков, например) - область, в которой возможны и необходимы исследования (соответственно есть почва для диссертаций) для оптимизации процесса программирования, выполнения, отладки программ и т. д.

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


Абсолютно верно, я с этим полностью согласен.
Именно новые иследования в кибернетике, информатике, математике приводят к созданию чего-то нового, что можно использовать при программировании.

Ну мое мнение во первых, что наука может обойтись и без теории. И тут как раз тот случай.
Лямбда-исчисление которое вы там увидели вовсе не теория, а нотация.
Да, там применяются символы из классических учебников математики, что вас и сбило с толку видимо.
Но таких абстракции в ООП тоже пруд пруди. И если ребята захотят они вам вооще 3-х этажные формулы нарисуют которые якобы описывают их абстракции.
Такой теории даже больше в учебниках по построению обычных процедурных языков. Почитайте "Компиляторы" от A.Ахо, Р.Сети, Д.Ульмана
Только это не та теория типа квантовой. Это просто свод правил и методов. Их тоже надо было открыть и изобрести и исследовать поэтому это наука. Но не теория, на основе этих методов новую парадигму программирования не создать. Это уже созданная и устаревшая парадигма, решавшая проблемы тогдашних неэффективных инструментов создания программ. Посмотрите когда книга была написана.




Ваше мнение понятно. Но оно не общепризнано и, скажем, непрогрессивно.

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

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

Вы безосновательно навязываете свое определение области в которой сами признали, что не разбираетесь.


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

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

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

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

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

..Видимо, все-таки, программирование и инженерная работа – занятия, отчасти творческие. Как и наука. То есть, не сводятся к теоремам, аксиомам и формулировкам.
Которые есть, что? Правильно, только инструмент.. И не один, а в числе других.
А общее решение есть только общее решение..

..Не помню случаев, когда программист идет к математику и просит его выдать алгоритм для написания программы. Ну, мне не встречались. Написание программы подразумевает то, что называют составлением алгоритма. Это можно назвать пониманием задачи в деталях. И это делает один человек, которого называют программистом. Далеко не всегда, программист, при этом, судорожно листает математические справочники..
Он может совсем не знать, что нечто, что он использовал, может быть, интуитивно, кто-то, математически, описал триста лет назад. А может и покопаться в талмудах. Если сочтет нужным. Ну и что..?

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

Опосредовано проблемы делают любую деятельность наукой.


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

Вот смотрим например свежую вакансию от Самсунга:
http://jobview.monster.com/GetJob.aspx?JobID=85751588

Что мы видим. Для программирования жалких мабил им нужен программист ученый(Doctor of Philosophy (Ph.D.))!
Я более чем уверен что недостатка там в кандидатах не будет.
Потому что каждый опытный программист уже почти ученый.

А основу так никто и не предложил (в виде определения терминологии), потому я и сделал свои выводы. А уж соглашаться с ними остальным или нет не мое дело. Я ни на что не претендую.

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

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

Бесспорно.

Выше объяснил отношение к творчеству.

Ну, если он что-то знает, хоть и интуитивно, то это уже очень хорошо. Другое дело, когда вообще ничего не знает и более того, попросту не хочет знать.

Представления такие складываются на фактических наблюдениях бестворческого подхода.

Опять же, если подходить творчески.

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