ИМХО в сравнении «джун vs сеньор» несколько факторов. Один из важных — это опыт. Программист-сеньор, как и опытный слесарь, как и опытная библиотекарша зачастую вспоминают похожую задачу, которую уже решали. Но иногда это решение может оказаться устаревшим и прилежный джун может найти (нпр., в инете) новое более эффективное решение, еще не успевшее стать общеизвестным. С этой точки зрения любой нетривиальный труд вписывается — такой своеобразный изоморфизм.
Когда занимался физ-хим. экспериментом в одном из ведущих НИИ АН СССР (РАН), часто заказывал нестандартные устройства/детали на опытном производстве при этом НИИ. Неоднократно слесари шестого разряда предлагали решение гораздо более технологичное для них и гораздо более удобное и надежное для меня. Там были «ювелирные работы». Но, к сожалению, не у всех слесарей 6-ой разряд. В том же НИИ пара опытных библиотекарей, часто не смотря в каталог, подсказывали наиболее востребованную книгу по узко-специальной теме. И физика и химия — очень большие, и в полном объеме их знать не в человеческих силах, и часто бывает нужной справка из области, с которой не имел до этого дела. Библиотекарши, проработав несколько десятков лет, запоминают десятки тысяч заголовков и могут сильно сэкономить время поиска нужного источника. Гуглу пока остается только мечтать о таком поиске. Чуть сложнее запрос — выбросит сотни тысяч ссылок, и только доли процента окажутся нужными (см., нпр., картинку — но это не самый тяжелый случай).
Для турбо-паруса нужен нагнетатель, а там говорилось об использовании только ветра. К сожалению, у меня нет ссылки, но можно поискать на сайтах старых журналов. Наверное, есть и более свежие обзоры.
Думаю единственные люди перед которыми программисты должны смиренно преклонить колени — это математики и физики.
Химиков забыли! Без них никаких компов бы не стояло — материалов бы не было :) И геологи нужны…
Но в целом ярко, увлекательно. Спасибо.
Немного про девушек и не только. Можно ведь в гостях на встрече Нового года получить вопрос про специальность.
Вы кое-что не учли. Давайте посчитаем. В этом зале сейчас примерно сотня людей. […] Ну в общем 25 процессоров на человека — вполне честное число. Итого получаем 25*100 — 2500 процессоров.
ИМХО слишком длинно, но важнее после " Итого получаем" сделать паузу. Если у Аллы хорошо с арифметикой, нпр., она продавщица в овощном магазине, то мгновенно умножит два числа и с радостью сообщит результат — во какая она умная. А если нет, то не надо, чтобы она почувствовала себя «дура дурой». Закатите глаза к потолку и скажите «ну в общем несколько тысяч». И расскажите какой-нибудь анекдот на тему IT. Но только понятный непосвященным. Нпр., бородатый анекдот, как глупая машина забросала гражданина счетами на 0.00$ и успокоилась только тогда, когда он сделал перевод на сумму 0.00. А вот тоже бородатый анекдот, как Вирт приехал в Испанию и сказал «Паскаль самый лучший ЯП». Ему ответили «Си, сеньор» — Вирт обиделся и уехал. — Поймут не все.
Япония занимает первое место по производству и использованию роботов. Так, в стране используется более половины (402 200 из 742 500) из всех произведённых индустриальных роботов[130]. В этой стране придумали таких роботов как QRIO, ASIMO и AIBO.
На Луне нет атмосферы и много солнечной энергии, поэтому «варить» такие металлы, как титан м.б. выгодно. + сила тяжести в 6 раз меньше, поэтому строить космические аппараты и запускать их с Луны м.б. выгоднее, чем с Земли. Нпр., спутники связи к Земле. Разгонять рельсотроном. Многие вредные и опасные производства м.б. перенесены на Луну. Тогда количество запусков ракет с Земли и количество потребляемой индустрией энергии снизятся — это благо для экологии Земли. ИМХО дело за более совершенными (чем сейчас) роботами.
Ага, спасибо. Именно про оттенки я и спросил. Нпр., доказывают корректность алгоритма (если доказывают, иначе называют «эвристическим» :), оценивают его теоретическую вычислительную сложность для наихудшего случая и т.д.
Как только обстоятельства чуточку меняются (мы называем это уточнением постановки задачи) вполне вероятно, что тот способ декомпозиции реальности, который нам секунду назад казался незыблемой вечной истиной, летит ко всем чертям. Если та декомпозиция уже была воплощена в иерархию классов, начинаем всё перепиливать. Или, если на это нет бюджета, расставлять миллион костылей.
Увы, это общая проблема моделирования. Модель всегда минимизирует свойства прототипа, т.е. отбираются только значимые свойства. Нпр., модель самолета для испытаний в аэродинамической трубе может быть сделана из монолитного куска дерева и не иметь двигателя, иллюминаторов, шасси и т.д. Для каких-то других испытаний придется выбросить деревяшку и изготовить другую модель, отражающую другие свойства прототипа. Про методологию мат.моделирования очень интересные книги:
Блехман И.И., Мышкис А.Д., Пановко Я.Г. Механика и прикладная математика. Логика и особенности приложений математики.
Мышкис А. Д., Элементы теории математических моделей. Изд. 3-е, исправленное. М.: КомКнига, 2007
Там на многих примерах показано, что только математики бывает недостаточно, нужны знание предметной области, здравый смысл и т.д.
При исследовании различных гипотез может оказаться, что две модели одного прототипа противоречат друг-другу. Тогда единая иерархия классов будет невозможна. Т.о. ИМХО ООП мощный и полезный инструмент, но каждый инструмент не универсален и имеет границы применимости, нпр., отверткой не надо забивать гвозди, а молотком саморезы. Когда без ООП можно обойтись — лучше ИМХО обойтись, если это не усложнит программу. (Disclaimer. Как и ко всем общим рекомендациям, к этой надо отнестись с большой осторожностью!)
Спасибо! Очень интересный получается разговор. Чтобы он был конкретнее, предложу в качестве примера собственный код. Там я поставил перед собой задачу показать различные способы представления графов, и ИМХО ООП для такой задачи очень подходит. А вот в послужившей отправной точкой программе игры "Из мухи слона" (МС) я не использовал ООП для выбранного представления графа (только для GUI). Как по-Вашему, это согласуется с принципами ООП типа SOLID? ;)
То есть это не самой реальности свойственно состоять из объектов, а нашему мышлению свойственно пребывать в полном недоумении до тех пор, пока мы не смогли с некоторой устраивающей нас степенью условности поделить единую реальность на объекты.
Делая программу МС, я не задумывался над выделением объектов «буква», «слово». Чаще просто определял по мере надобности локальные переменные. «Объект» Граф — это просто несколько массивов: один — двумерная матрица смежности с элементами Булева типа, где элемент (i,j) равен истине, если существует ребро между вершинами i и j, другой массив — вектор, где компонента i — слово (стандартная строка string) из словаря существительных русского языка, и т.д. Все операции осуществлял через простые процедуры и функции, но не методы ООП. ИМХО через ООП все то же самое выглядело бы академичнее, но код был бы большего размера, а выигрыша никакого. (Тем более, что не преследовал цели публиковать код).
Могут такие примеры спасти молодых бойцов от шаманских бубнов?
ИМХО в первую очередь стоит упомянуть о принципиальной разнице между
сomputer science (CS) и математикой. Первая (как отметили Аллен Ньюэлл
и Герберт Саймон в своей лекции на вручении премии Тьюринга) экспериментальная наука, а вторая нет. Но математика и CS имеют области пересечения. Теория типов — одна из таких областей. Чистый мат. подход нужно искать у Рассела — см. в вики статью «парадокс Рассела». — Там не просто математика, а мат. логика, которую иногда противопоставляют обычной «недостаточно строгой» математике. Обратите внимание на секцию «Влияние на математику» — в числе прочего такое нехилое направление, как интуиционизм.
В CS, пожалуй, подход более приземленный, ближе к практике, частично инженерный. В принципе, не слишком сложную программу можно написать в машинных кодах не прибегая к явной типизации данных и к ООП. Но тут на первый план выступает человеческий фактор — человек недостаточно аккуратен, чтобы выполнять такое кодирование. Трудоемкость даже для составления небольшой программы будет запредельной. Я только хочу сказать, что многие вещи в ЯП появились не из-за объективной необходимости (не из-за свойств окружающего мира, физики, математики), а из-за свойств человеческого сознания — в частности, из-за свойства делать такие ошибки, которые исправный комп никогда не сделает.
Но всякая монета имеет оборотную сторону. Как Вы справедливо отметили, платой за всевозможные фреймворки является тормознутость. Тут ИМХО многое зависит от общей проф.культуры программиста. Почти всегда можно найти золотую середину. Но не все умеют, а многие не хотят, а хотят спихнуть работу быстрее, чтобы хоть как-то работало.
BTW интересно, что многие популярные ЯП не требуют обязательного применения ООП. Интересно, что и многие алгоритмы (не только старые, но и новые) описывают на псевдокоде без ОО. Я зачастую делаю на ООП только GUI. Нпр., когда хочу проверить собственный алгоритм.
В математике, логике и компьютерных науках теорией типов считается какая-либо формальная система, являющаяся альтернативой наивной теории множеств, сопровождаемая классификацией элементов такой системы с помощью типов, образующих некоторую иерархию. Также под теорией типов понимают изучение подобных формализмов.
Теория типов — математически формализованная база для проектирования, анализа и изучения систем типов данных в теории языков программирования (раздел информатики). Многие программисты используют это понятие для обозначения любого аналитического труда, изучающего системы типов в языках программирования. В научных кругах под теорией типов чаще всего понимают более узкий раздел дискретной математики, в частности λ-исчисление с типами.
Современная теория типов была частично разработана в процессе разрешения парадокса Рассела и во многом базируется на работе Бертрана Рассела и Альфреда Уайтхеда «Principia mathematica»[1].
Как видим ноги растут из теории множеств (как и у др. теорий современной математики). Мне как программисту в первую очередь вспоминаются классические книги:
Дал У., Дейкстра Э., Хоор К., Структурное программирование. М.:«Мир», 1975.
Н.Вирт, К. Иенсен. Паскаль. Руководство для пользователя и описание языка. М.: Финансы и статистика, 1982 ;
Алгоритмы + структуры данных = программы. М.: Мир, 1985;
С точки зрения этого подхода классы ООП естественным образом выглядят, как расширения паскалевских записей (type record) начиная с turbo-Pascal 5.5 и Think Pascal до Delphi 7. (Более поздние версии Дельфи могут больше, но ИМХО цена за это — частичная утрата первоначальной стройности).
про множественное наследование
ИМХО очень яркая вспышка холивара произошла в процессе принятия спецификации CORBA, т.к. у OMG был принцип достижения полного консенсуса среди участников, а участвовали лидеры IT индустрии. Если поднять выпуски OMG First Class Newsletter, можно отследить доводы сторонников и противников, вполне разумные ИМХО попытки примерить множественное наследование с теорией типов.
Паскаль возник как обучающий язык, эта особенность перешла и в ОО Паскаль, где ради теоретической стройности множественное наследование не поддерживалось. Си, напротив, возник как практический язык, у которого на первом месте была эффективность и гибкость. С++ постарался перенять эти цели. Лично я сторонник паскалевского подхода и считаю, что принципы защитного программирования (в том числе и строгости типизации данных) для современного ПО важнее черезмерной гибкости ЯП. Общемировая практика показывает, что обилие ненадежного ПО может привести к техногенным катастрофам с тяжелыми последствиями.
Про математику нет единого мнения, см., нпр., этот опрос — вопрос: «Роль математики для информатики в школе высокая».
ИМХО математика очерь нужна программисту, но в списке статьи топология — это непонятно, где топология в программировании, указана теория графов и там топология (не геометрия) — это Ok — нужно, но мат. дисциплина топология, где ее практически применить в кодах?
PS Не указана теория сложности вычислений. М.б. я просмотрел, м.б. иначе названа?
Вот у нас есть ООП. Инкапсуляция, наследование, полиморфизм. В чём математическая основа этой штуки? Теория множеств? Или группы? Или категории? Как базовые понятия (объект, класс, атрибут, метод) мэппятся на математику?
Студентам необходимо научиться гораздо лучше отличать в своем обучении полезное от бесполезного.
По многим предметам и навыкам нет единого мнения, см., нпр., этот опрос — вопросы:
«Роль математики для информатики в школе высокая», «В школе нужно учить быстро печатать на ПК». (ИМХО для вуза будут схожие ответы).
Интересно, что в спорах о ветряках зачастую забывают исторический аргумент: энергия ветра уже успешно использовалась на протяжении веков — это ветряные мельницы и парусные корабли. Сейчас на очередном витке исторической спирали история повторяется, но на уровне современных технологий. В журнале Катера и яхты советских времен был интересный обзор иностранной прессы с проектами современных парусников — мачты-цилиндры с сервоприводами, на которые (мачты) намотан парус. Т.о. не нужно, как раньше, большой команды для постановки парусов + связь со спутником помогает оптимизировать курс в зависимости от погодной обстановки. Утверждалось, что это будет оптимально для перевозок малой скоростью — бананы возить не стоит, а многотонные турбины в самый раз.
Сравнение языков — тема, которая, видимо, никогда не потеряет актуальности, что доказывают регулярные холивары. Видимо, в таких сложных вопросах не может быть идеальных рейтингов. Взять, нпр., индексы цитируемости н-т. литературы. Предполагается, что высокий индекс показывает востребованность данного источника. С этим можно согласиться. Но из этого зачастую делается неверный вывод, что чем выше индекс — тем лучше источник. А это не всегда так — может быть ситуация, когда одиозную статью поминают только для того, чтобы пнуть. Парадокс Герострата — мало кто помнит, кто построил храм, но все помнят, кто его сжег. Поиск документации на ЯП может, нпр., означать не что на нем много пишут, а что с него много переводят ранее написанное. При всех очевидных минусах рейтингов их явно или неявно широко используют для продвижения и выбора продуктов, а от индексов цитируемости явно или неявно зависит ЗП и гранты научных сотрудников многих НИИ и универов. Даже ссылка в Википедии зачастую зависит от индекса-рейтинга.
Химиков забыли! Без них никаких компов бы не стояло — материалов бы не было :) И геологи нужны…
Но в целом ярко, увлекательно. Спасибо.
Немного про девушек и не только. Можно ведь в гостях на встрече Нового года получить вопрос про специальность.
ИМХО слишком длинно, но важнее после " Итого получаем" сделать паузу. Если у Аллы хорошо с арифметикой, нпр., она продавщица в овощном магазине, то мгновенно умножит два числа и с радостью сообщит результат — во какая она умная. А если нет, то не надо, чтобы она почувствовала себя «дура дурой». Закатите глаза к потолку и скажите «ну в общем несколько тысяч». И расскажите какой-нибудь анекдот на тему IT. Но только понятный непосвященным. Нпр., бородатый анекдот, как глупая машина забросала гражданина счетами на 0.00$ и успокоилась только тогда, когда он сделал перевод на сумму 0.00. А вот тоже бородатый анекдот, как Вирт приехал в Испанию и сказал «Паскаль самый лучший ЯП». Ему ответили «Си, сеньор» — Вирт обиделся и уехал. — Поймут не все.
Там на многих примерах показано, что только математики бывает недостаточно, нужны знание предметной области, здравый смысл и т.д.
При исследовании различных гипотез может оказаться, что две модели одного прототипа противоречат друг-другу. Тогда единая иерархия классов будет невозможна. Т.о. ИМХО ООП мощный и полезный инструмент, но каждый инструмент не универсален и имеет границы применимости, нпр., отверткой не надо забивать гвозди, а молотком саморезы. Когда без ООП можно обойтись — лучше ИМХО обойтись, если это не усложнит программу. (Disclaimer. Как и ко всем общим рекомендациям, к этой надо отнестись с большой осторожностью!)
Делая программу МС, я не задумывался над выделением объектов «буква», «слово». Чаще просто определял по мере надобности локальные переменные. «Объект» Граф — это просто несколько массивов: один — двумерная матрица смежности с элементами Булева типа, где элемент (i,j) равен истине, если существует ребро между вершинами i и j, другой массив — вектор, где компонента i — слово (стандартная строка string) из словаря существительных русского языка, и т.д. Все операции осуществлял через простые процедуры и функции, но не методы ООП. ИМХО через ООП все то же самое выглядело бы академичнее, но код был бы большего размера, а выигрыша никакого. (Тем более, что не преследовал цели публиковать код).
Могут такие примеры спасти молодых бойцов от шаманских бубнов?
сomputer science (CS) и математикой. Первая (как отметили Аллен Ньюэлл
и Герберт Саймон в своей лекции на вручении премии Тьюринга) экспериментальная наука, а вторая нет. Но математика и CS имеют области пересечения. Теория типов — одна из таких областей. Чистый мат. подход нужно искать у Рассела — см. в вики статью «парадокс Рассела». — Там не просто математика, а мат. логика, которую иногда противопоставляют обычной «недостаточно строгой» математике. Обратите внимание на секцию «Влияние на математику» — в числе прочего такое нехилое направление, как интуиционизм.
В CS, пожалуй, подход более приземленный, ближе к практике, частично инженерный. В принципе, не слишком сложную программу можно написать в машинных кодах не прибегая к явной типизации данных и к ООП. Но тут на первый план выступает человеческий фактор — человек недостаточно аккуратен, чтобы выполнять такое кодирование. Трудоемкость даже для составления небольшой программы будет запредельной. Я только хочу сказать, что многие вещи в ЯП появились не из-за объективной необходимости (не из-за свойств окружающего мира, физики, математики), а из-за свойств человеческого сознания — в частности, из-за свойства делать такие ошибки, которые исправный комп никогда не сделает.
Но всякая монета имеет оборотную сторону. Как Вы справедливо отметили, платой за всевозможные фреймворки является тормознутость. Тут ИМХО многое зависит от общей проф.культуры программиста. Почти всегда можно найти золотую середину. Но не все умеют, а многие не хотят, а хотят спихнуть работу быстрее, чтобы хоть как-то работало.
BTW интересно, что многие популярные ЯП не требуют обязательного применения ООП. Интересно, что и многие алгоритмы (не только старые, но и новые) описывают на псевдокоде без ОО. Я зачастую делаю на ООП только GUI. Нпр., когда хочу проверить собственный алгоритм.
Как видим ноги растут из теории множеств (как и у др. теорий современной математики). Мне как программисту в первую очередь вспоминаются классические книги:
С точки зрения этого подхода классы ООП естественным образом выглядят, как расширения паскалевских записей (type record) начиная с turbo-Pascal 5.5 и Think Pascal до Delphi 7. (Более поздние версии Дельфи могут больше, но ИМХО цена за это — частичная утрата первоначальной стройности).
ИМХО очень яркая вспышка холивара произошла в процессе принятия спецификации CORBA, т.к. у OMG был принцип достижения полного консенсуса среди участников, а участвовали лидеры IT индустрии. Если поднять выпуски OMG First Class Newsletter, можно отследить доводы сторонников и противников, вполне разумные ИМХО попытки примерить множественное наследование с теорией типов.
Паскаль возник как обучающий язык, эта особенность перешла и в ОО Паскаль, где ради теоретической стройности множественное наследование не поддерживалось. Си, напротив, возник как практический язык, у которого на первом месте была эффективность и гибкость. С++ постарался перенять эти цели. Лично я сторонник паскалевского подхода и считаю, что принципы защитного программирования (в том числе и строгости типизации данных) для современного ПО важнее черезмерной гибкости ЯП. Общемировая практика показывает, что обилие ненадежного ПО может привести к техногенным катастрофам с тяжелыми последствиями.
ИМХО математика очерь нужна программисту, но в списке статьи топология — это непонятно, где топология в программировании, указана теория графов и там топология (не геометрия) — это Ok — нужно, но мат. дисциплина топология, где ее практически применить в кодах?
PS Не указана теория сложности вычислений. М.б. я просмотрел, м.б. иначе названа?
Теория типов.
«Роль математики для информатики в школе высокая», «В школе нужно учить быстро печатать на ПК». (ИМХО для вуза будут схожие ответы).
М.б. правильнее «I want to sleep»?