Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет chistyakov ([info]chistyakov)
@ 2005-06-11 16:11:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Прежде, чем именовать себя программистом, надо знать, что такое ЭВМ
Стала ясной причина научно-технического невежества "программистов".

Оказывается, они не знают, что такое ЭВМ. Что для неё характерно? Что именно отличает ЭВМ от, например, термореле утюга? Почему программируемая логическая матрица (ПЛИС -- программируемая логическая интегральная схема, "плиска") не является ЭВМ, а самый захудалый микропроцессор является?

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

В приступе педагогической щедрости формулирую единственный существенный признак ЭВМ:

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

Это ВСЁ! И все чудеса, связанные с ЭВМ, проистекают из этого существенного признака и без него невозможны.

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

Теперь можно смело садиться программировать. Без мистики и фанатизма.
Бог в помощь, господа программисты! Знание -- сила.

Носителей идеологий "виртуальных машин" просят не беспокоиться. Все места заняты.

{+}


(Читать комментарии) - (Добавить комментарий)

Re: :)
[info]vap@lj
2005-07-05 14:13 (ссылка)
В итоге выяснилось, что употребление goto -- дурной тон
А потом выяснилось, что некачественная (в пределе - ее отсутствие) инкапсуляция данных и операций - тоже дурной тон, и ровно по той же причине :)

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: :)
[info]ex_chistyak@lj
2005-07-05 14:54 (ссылка)
Ну, структурное программирование как раз и не отрицает инкапсуляции, наоборот. К сожалению, ограниченность ресурсов, которая бывает в дешёвых микропроцессорных системах, не позволяет провести инкапсуляцию "до дна". Приходится держать довольно большой массив глобальных переменных. Искупается сокращением количества "программистов".

{+}

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: :)
[info]vap@lj
2005-07-05 15:33 (ссылка)
Ограниченность ресурсов крайне слабо относится к инкапсуляции. Инкапсуляция - свойство языка, а машинный код (и его требования к ресурсам) в общем случае не изменяется.
Например, простое добавление модификатора static к описанию статической переменной в файле на Си делает эту переменную невидимой снаружи того же объектного файла, и является простейшим приемом инкапсуляции. Но машинный код с появлением этого модификатора не изменится ни на байт.

Насчет сокращения числа "программистов": от языка программирования наличие кавычек вокруг этого слова не зависит. Программисты - это прежде всего специалисты по выражению задач из предметной области в способ решения этих задач на машине. Многие задачи предметной области лучше (лаконичнее, проще, и в конце концов безошибочнее) описываются не в тех терминах, которые близки к архитектуре машины. Для таких задач нужны дополнительные слои абстракции, так как в их отсутствие их элементы придется изобретать заново в конкретном проекте, совершая все ошибки. "Наиболее эффективный способ реализации некоторых проектов, скажем, не используя язык Лисп: разработать что-то похожее на интерпретатор Лиспа и решать задачу уже на нем". Банковские приложения тоже нужны, и разрабатывать их лучше с использованием EJB, поскольку в противном случае придется реализовать все основные службы EJB самостоятельно.

Другой вопрос - это кадровая политика. Нет смысла брать на работу в низкоуровневый embedded-проект людей, которые по складу ума более годны для высокоуровневой работы, и наоборот.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: :)
[info]ex_chistyak@lj
2005-07-05 16:22 (ссылка)
Я с Вами совершенно не согласен по многим затронутым Вами вопросам, но, увы, сейчас у меня нет времени Вам ответить подробно.
Коснусь только "программистов". Как Вы поняли, это для меня самый ненавистный сорт людей. Я люблю инженеров. Инженер может решить любую задачу, в том числе, и программируя ЭВМ. "Программист" же просто не в состоянии понять, что требуется, а сосредоточивается на самом процессе программирования.

(Ответить) (Уровень выше)

Re: :)
[info]ex_chistyak@lj
2005-07-05 16:37 (ссылка)
Я с Вами совершенно не согласен по многим затронутым Вами вопросам, в том числе и по переменным static, но, увы, сейчас у меня нет времени Вам ответить подробно. Просто, мне кажется, что Вы не представляете себе, что означает словосочетание "ограниченные ресурсы".
Коснусь только "программистов". Как Вы поняли, это для меня самый ненавистный сорт людей. Я люблю инженеров. Инженер может решить любую задачу, в том числе, и программируя ЭВМ. "Программист" же просто не в состоянии понять, что требуется, а сосредоточивается на самом процессе программирования.

(Ответить) (Уровень выше) (Ветвь дискуссии)

Re: :)
[info]vap@lj
2005-07-05 19:42 (ссылка)
Просто, мне кажется, что Вы не представляете себе, что означает словосочетание "ограниченные ресурсы".
Это понятие, как и любое, введенное человеком, можно трактовать по-разному. В рамках данного обсуждения, в применении к обсуждению "затрат ресурсов на синтаксические и архитектурные рюшечки", для меня ограниченные ресурсы - это, упрощенно, 512-4096 байт ОЗУ и 8-128К программного Flash. То, что ниже (скажем, когда все ОЗУ - это 32 регистра, и стека вообще нет) - действительно может потребовать принципиально другого подхода, но там и уровень сложности доступных для решения задач позволяет со сложностью просто не бороться.

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

Пример того, для чего программист-системщик нужен: стоит на Мурманском шоссе недалеко от Питера два комплекса, наш и конкурентов. Проекты одного уровня сложности и в чем-то даже перекрывающиеся по функциональности. Недели три назад была сильная гроза. Оба комплекса получили по сбою, но аппаратура уцелела. Однако, у конкурентов сбой сразу стал отказом, а наш всего лишь не прошел периодическое самотестирование и автоматически перезапустился еще до того, как нам дозвонились о проблеме.
Резюмирую вышесказанное: программист-системщик - это инженер по сложности и смежным вопросам. Он занимается в числе прочего и задачами надежности, в том числе обеспечением того, чтобы сбой не становился отказом. Думаю, излишне говорить, что "просто инженер, заодно еще и программирующий" вряд ли нормально обеспечит это - он просто не будет знать ни о наличии проблемы, ни о типовых путях ее решения. В каждом деле нужны специалисты. Что, конечно же, не отменяет необходимости знать смежные области и быть способным решать часть проблем самостоятельно - к примеру, я, программист, вполне могу на равных обсуждать и править P-CAD-овскую схему железки с нашим аппаратчиком, или, к примеру, собственноручно спаять себе домой программатор, не бегая для этого в цех, а наш программист-гуевщик со знанием дела обсуждает со мной сетевые протоколы и способен указать на проблему в них.

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

(Ответить) (Уровень выше)


(Читать комментарии) -