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

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


Сообщение отредактировал Ko4egap - Jan 22 2010, 14:43

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



И что - каждый пункт - практически 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-е нормальный спец уже должен знать как минимум язык разработки скриптов.