Можем ли мы увидеть карьеру из каменщика в инженеры?
Все бывает в этой жизни. Имел честь быть знакомым с директором регионального филиала крупнейшей телекоммуникационной компании, который начал карьеру с линейного монтера, т.е. он когда-то тянул и скручивал кабель, но у него была цель.
Не все так плохо. Мы принципиально не объясним полупроводниковому роботу что такое «первая любовь», просто потому что у робота нет и не будет мозгов, половых органов и др. чисто биологических атрибутов.
Но его вполне можно научить таким понятиям, как:
— скорость движения;
— качество покрытия дороги;
— направление движения;
— наличие препятствий.
— мотивация к действию (как значение некоторой функции)
Дополнив эту модель концептом «поиск другого робота с комплиментарным форм-фактором разъема передачи данных», уже можно говорить о машине в некотором смысле понимающей, что такое «одиночество», «грусть», «поиск половинки», «пропасть, разделяющая нас двоих» и т.д.
Допустим, мы хотим построить модель предприятия с целью автоматизации бизнес-процессов.
Я уверен, что если дать задание трем разным аналитикам построить модель 1 предприятия, в результате моделирования будут получены 3 разные модели.
И сразу возникают вопросы:
— Почему мы описывали 1 предприятие, а получили 3 разных модели?
— Какая из трех моделей «правильная»?
— Что означает «правильная» модель?
Этими вопросами, на мой взгляд, и должна заниматься онтология. В идеале хотелось бы иметь метод построения «правильных» моделей.
Спасибо за ссылку! Скажите, в этой книге материалы чисто теоретического плана или выросшие из практики? Вы реально применяете изложенное в каких-либо проектах?
Приведенные рассуждения, прежде всего, ставят вопрос о достаточности, адекватности традиционного подхода к описанию предметной области с использованием классификации, основанной на теории множеств.
Не совсем понимаю, почему классификация, основанная на теории множеств стала традиционным подходом? Когда? В какой традиции?
Классификации строил еще еще Аристотель, когда теории множеств и в проекте не было. К XVIII веку научились классифицировать растения, животных и минералы уже совершенно ясно осознавая принципы, по которым должны строиться классификации. А теории множеств все еще не было.
Еще в детстве читал про полином Жегалкина, но до сих пор не знаю: есть ли у него какое-либо практическое применение? Зачем представлять булеву функцию в этой форме?
Я не говорил, что программировать просто. Я говорил, что есть в принципе более сложные занятия.
Сложность «программирования» сильно зависит от сложности решаемых программой прикладных задач.
По-поводу склада ума — это верно. Но так дела обстоят в любой профессии, требующей высокой квалификации.
Программирование здесь не исключение.
И с футболом в России дела обстоят еще хуже, чем с программированием.
Настоящий, «правильный» программист — он как бесконечный разум из «Теории доказательств» Гаиси Такеути.
Он способен перебрать бесконечное множество строчек кода за конечное время.
Перед таким — трепещи аналитик, от такого — беги прочь тестировщик, сторонись его ПМ, избегай его заказчик.
Я, кстати, тоже. По мне идеал в программировании — это меньше работать, меньше писать код. В идеале просто говорить машине: сделай мне вот это и вот это. Но это увы, недостижимый идеал.
Все бывает в этой жизни. Имел честь быть знакомым с директором регионального филиала крупнейшей телекоммуникационной компании, который начал карьеру с линейного монтера, т.е. он когда-то тянул и скручивал кабель, но у него была цель.
Сделайте этот проект хорошо, и удача вам улыбнется.
Но его вполне можно научить таким понятиям, как:
— скорость движения;
— качество покрытия дороги;
— направление движения;
— наличие препятствий.
— мотивация к действию (как значение некоторой функции)
Дополнив эту модель концептом «поиск другого робота с комплиментарным форм-фактором разъема передачи данных», уже можно говорить о машине в некотором смысле понимающей, что такое «одиночество», «грусть», «поиск половинки», «пропасть, разделяющая нас двоих» и т.д.
Допустим, мы хотим построить модель предприятия с целью автоматизации бизнес-процессов.
Я уверен, что если дать задание трем разным аналитикам построить модель 1 предприятия, в результате моделирования будут получены 3 разные модели.
И сразу возникают вопросы:
— Почему мы описывали 1 предприятие, а получили 3 разных модели?
— Какая из трех моделей «правильная»?
— Что означает «правильная» модель?
Этими вопросами, на мой взгляд, и должна заниматься онтология. В идеале хотелось бы иметь метод построения «правильных» моделей.
Не совсем понимаю, почему классификация, основанная на теории множеств стала традиционным подходом? Когда? В какой традиции?
Классификации строил еще еще Аристотель, когда теории множеств и в проекте не было. К XVIII веку научились классифицировать растения, животных и минералы уже совершенно ясно осознавая принципы, по которым должны строиться классификации. А теории множеств все еще не было.
Так при чем здесь теория множеств?
Сложность «программирования» сильно зависит от сложности решаемых программой прикладных задач.
По-поводу склада ума — это верно. Но так дела обстоят в любой профессии, требующей высокой квалификации.
Программирование здесь не исключение.
И с футболом в России дела обстоят еще хуже, чем с программированием.
Нет, все же, это вредная статья, потому что способствует дезинформировании молодежи и разжиганию ЧСВ.
Программирование — это всего лишь работа. Порой творческая, порой не очень.
Программирование — намного проще, чем теоретическая физика.
Проще, чем теория алгебраических многообразий.
Проще, чем дискретная математика (если не верите — откройте «Теорию моделей» Робертсона).
И для многих программистов оно даже проще, чем игра в футбол.
В программировании очень много рутины.
Это сидячая работа, чреватая ожирением, остеохондрозом и проблемами со зрением.
Но программистам хорошо платят.
Он способен перебрать бесконечное множество строчек кода за конечное время.
Перед таким — трепещи аналитик, от такого — беги прочь тестировщик, сторонись его ПМ, избегай его заказчик.